1. Manalyzer can now generate traffic on token ring networks.
2. Real-time graphs have been added as another capture display. Three graphs are displayed to show the bandwith per unit of time, the average packet size and the number of packets transmitted per second. The rate at which there are updated can be set from 1 second to 65000 hours. Each graph can be rescaled like the packets/second bar graph at the bottom of the capture screen.
3. Manalyzer can now save data that was captured to memory.
4. When generating network traffic, there is now the option to not monitor the other traffic on the network. This will signifcantly improve the maximum performance of the token ring traffic generator.
5. A menu item called “Slot Info…” has been added. This item will identify the cards in each slot of the machine and their revision level. This can be useful for identifying the correct slot in the Capture Setup and Transmit Setup dialogs.
6. Manalyzer can now add sound to help indicate the level of network traffic while capturing data. The higher the percentage that the bar graph is filled, the higher the pitch of the sound. Under normal situations, the traffic varies enough that the sound changes so rapidly that it is quite annoying. But, we have found that under test situations with controlled amounts of traffic, the sound can be useful. The volume of the sound is controlled by the Control Panel.
7. The Capture Filter dialog has a checkbox to not capture any network traffic. This is usefull for when the capture display is enough information and the traffic content isn’t important. By not taking the time to filter and capture the network data, the maximum performance is much higher.
8. Fixed a bug with byte filters where if frames were smaller than the specified offset, it might still pass the filter.
Changes made from 2.0d1 to 2.0d2
1. When examing the contents of a packet, the time since the last packet and the time since the capture started will be displayed. With many capture engines, this time will be based on the time that the packet was copied to the main buffer, not when the packet was received so this may be slightly inaccurate. When using drivers of this nature, the time will be prefaced with a “~” to indicate this.
Changes made from 1.0d1 to 2.0d1
1. Manalyzer now supports the John Galt Ethernet card.
2. Manalyzer can now generate background traffic for use in testing how a network responds to different traffic levels. Packets can consist of any repeated byte or can be defined by a file of ASCII hex bytes separated by white space. The packets can be directed back to the sender or can be sent to any desired node. Minimum and maximum packet sizes can be specified along with the desired amount of network traffic to add.
3. Packets can be saved to memory. Once a capture is halted, the buffer will contain up to the last 200K of captured data.
4. The capture display has been changed in many aspects. The capture window contains more information and there are 3 different displays that can be generated. The different options are specified by using the Capture Setup dialog.
The node-to-node transaction list is similar to the way it was in the last release of Manalyzer. The enhancements are that now it has a title and won’t overwrite the rest of the screen when there are too many entries. Clicking on the title will restart the list. If auto-update is selected in the Capture Setup dialog, the list will be restarted every minute if the list is full.
A new feature is that during capture, the most active nodes can be displayed. Every 5 seconds, the display will be updated with the top 20 most active nodes since the capture started. Each entry of the list will contain the node ID, the packets sent, bytes sent, packets received and bytes received. The list is sorted based on the total number of packets sent and received. Internally the capture engines keep a hashed list of up to 1024 different nodes.
Another new display is the network errors display. This format of this display is network dependent. On Ethernet networks, error packets are received, and if the packet is more than 30 bytes long, the node generating the error is stored in a hash table and a display is generated showing the nodes that are causing the most errors. On Token Ring networks, the capture engine intercepts all packets directed at the error monitor and a display is generated of the nodes having the most errors. This display is updated every 5 seconds. Clicking on the title forces an update of the list.
The last new display is a display showing how other nodes have communicated with a target node. In the Capture Setup dialog, you specify a target node. A display is generated showing a sorted list of all nodes that the target node has communicated with since the capture started. The display will show the how many packets and bytes nodes have sent and received from the target node. This list is sorted by the number of packets sent and received.
Underneath the running capture display are 2 status lines showing how many packets were accepted and rejected, average packet size, total traffic that has been transmitted on the network, the current bandwidth used of the network and the maximum bandwidth that was seen on the network. This status list is updated 5 times a second.
Beneath the status lines is the bar graph of packets per second. In this version, the graph should be slightly more accurate than it was in pervious versions. As before, clicking on the graph toggles it between a linear or logarithmic scale. Above the title for this graph are two arrows. Clicking on them will increase or decrease the range of the graph. The minimum range of a graph is 100, the maximum range is 9000. By default the Token Ring graph has a maximum value of 1000 packets per second and the Ethernet default value is 3000 packets per second. Your mileage may vary of course. Though no matter the level of network traffic, there should be a combination of ranges and scale of graph that satisfies everyone.
At the bottom of the screen are card dependent statistics. Generally these are only useful to someone doing low level testing of a network. For example, on the John Galt card these statistics range from fairly useful items like the number of CRC errors to rather obscure and esoteric information like the number of RBAE (Receive Buffer Area Exhausted Errors) encountered. The odds are that if you don’t know what a statistic is, you probably can ignore it.
5. Capture filtering and display filtering has been greatly expanded from earlier versions of Manalyzer. Along with the protocol filtering, there is now node and byte filtering. With node filtering, up to 3 source and three destination nodes (or their aliases) can be specified. If both source and destination nodes are specified, one of the source nodes must match the source node of the packet and one of the destination nodes must match the destination node of packet. There is a checkbox to allow reverse packets. By specifying a source node and allowing reverse packets you could capture all packets either to or from a particular node. Specifying a source and destination node and allowing reverse packets would let you capture all traffic between two nodes.
Byte filters allow you to specify that at a particular offset in the packet, the byte must be less than, greater than, equal to, or not equal to a target value. If there is more than 1 byte filter set, the packet need only satisfy one of the them to pass the filter. Up to 3 byte filters are allowed.
The protocol filtering available in version 1.0 has remained and has been expanded to include Ethernet networks. On Ethernet 802 packets the SAP and DSAP filters function like they do on Token Ring networks but the MAC filter has no effect. On Ethernet packets that don’t conform to the the IEEE 802 packet formats, such as Phase I EtherTalk packets, the DSAP and SAP filters are ignored, but these packets are only accepted if Other is selected.
6.. A dialog has been created so node aliases can be created. When selected, the Add Alias dialog will let you select the source or destination node of the current packet. The other option is to type the node ID of the node to make an alias for. A dialog has also been added to delete node aliases. Each network type has its own alias list.
7. The formatted packet display has been enhanced to display the contents of AppleTalk Phase I and Phase II packets. An effort has been made to make the display as useful as possible by displaying the fields in whatever forms is most appropriate be it hex or decimal or ASCII and whether to display data as bytes, words, longs or strings. The higher level protocols built upon ATP (PAP, ASP,and AFP ) are not broken down in this version.
8. The command key equivalent for displaying the first packet in the list is now ‘1’. The command key equivalent for moving to the last packet in the display list is now ‘9’. Although it isn’t very obvious, -2 through -8 will move proportionally through the list.
9. Many changes were made to improve the human interface of the product: menus should now dim when appropriate, OK buttons are outlined, escape and -. act like cancel in dialogs, there are more precise error messages, graphs and displays are now labeled, dialogs and alerts are now centered, the cursor is now appropriate, windows now update correctly, key equivalents have been added to menu items, dialog items now line up, etc.
10. When loading saved capture files, Manalyzer will now try to cache the document. This can decrease the load time by over a factor of 10. If the file is under 1 megabyte, it can almost always be cached.
11. The About box has a new look and the application and document icons have been updated.
